ターゲットトラッキングポリシーを利用した、EC2のオートスケール設定を実施してみた

はじめに

AWSチームのすずきです。

2017年7月のアップデートにより、「ターゲットトラッキングポリシー」を利用したEC2のオートスケール設定が可能になりました。

新機能 – EC2 Auto Scalingのターゲットトラッキングポリシー

今回、ALB(Application Load Balancer)のターゲット別リクエスト数が指定した値を超過した場合のスケールアウト設定を、「ターゲットトラッキングポリシー」利用して設定する機会がありましたので、紹介させて頂きます。

構成図

• 一般的なWeb3層システム、ELBはALBを採用するシステムです。

設定

Auto Scaling グループ設定

スケーリングポリシーの作成

• ターゲットトラッキングポリシーとして、「ターゲット別の Application Load Balancer リクエストの数」を指定した設定を実施しました。

• オートスケールの発動によりEC2インスタンスの起動、撤去が繰り返される事を回避するため、スケールインは無効としました。
• ターゲットトラッキングポリシーの対象としては、EC2のCPU使用率、EC2のネットワーク転送量を利用する事も可能です。

スケジュールされたアクションの設定

• スケジュールされたアクションとして、平時予想される負荷に応じたEC2台数を希望数、最小数として設定しました。
• 予想以上のリクエストが発生した場合、ALBのリクエスト数をターゲットトラッキングポリシーとしたスケールアウトを発動させる想定で、最大数を設定しました。
• リクエストが収束する夜間、希望数、最小数を減らすスケールイン設定をしました。

確認

Cloudwatch アラーム

• 作成したスケーリングポリシーは、Cloudwatchのアラームとして確認が可能です。

• 指定したしきい値を超過するとアラームの状態がOKからALARMとなり、オートスケールが発動した事を確認できました。

Cloudwatch ダッシュボード

-ApplicationELB、Auto Scaling、EC2のAuto Scaling グループ別のメトリックを一覧で比較するため、Cloudwatch ダッシュボードに登録しました。

ALB情報

• HTTP応答コード別のリクエスト数、ターゲット別のリクエスト数、ターゲットの応答時間を確認しました。
• ターゲットの応答時間、90〜99%タイルの値が悪化しない事を目標に、オートスケール設定を調整します。

• 今回のスケールアウトの発動はやや早すぎた可能性が高く、しきい値を高め、EC2の起動台数を抑える方向で調整しました。

Auto Scaling、EC2

• オートスケールの発動によりインスタンスが増加し、EC2、1台あたりのCPU負荷(CPU Utilzation)が減少した事を確認できました。

• インスタンスファミリー「t2」を利用する場合、CPUクレジットの枯渇はシステム性能に大きな影響を及ぼします。オートスケールのしきい値調整の際、CPUCreditBalanceの値を指標として、合わせて確認する事をおすすめします。

まとめ

「ターゲットトラッキングポリシー」を利用する事で、オートスケールをより簡単、直感的に設定する事ができる様になりました。

リクエスト数に比例してEC2(Web/APサーバ)の負荷が上昇するシステムでは、 ALBのターゲット別リクエスト数をトラッキングポリシーとした設定は有効と考えられます。予期せぬ負荷が発生した場合の保険として是非ご活用ください。